Perfctl, un malware Linux tenace
Perfctl storm
Hier soir, les chercheurs de la société Aqua Security ont publié un article détaillé sur le malware Perfctl. Ils y mettent en garde les utilisateurs contre ses capacités, qui allient une grande discrétion à une persistance tenace. Sa détection n’est pas assurée et les chercheurs estiment que le nombre de configurations vulnérables se comptent en millions.
Le 04 octobre à 12h15
6 min
Sécurité
Sécurité
Le nom du malware, donné par les chercheurs, est un agrégat de Perf, un outil d’analyse des performances, et de ctl, une abréviation courante pour les outils en ligne de commande. Selon Aqua Security, ce logiciel malveillant circule depuis au moins 2021 et serait présent sur au moins plusieurs milliers de configurations, pour l’essentiel des serveurs.
Un roi de l’évasion et de la persistance
Perfctl dispose de nombreuses capacités. Sitôt installé sur une machine, il supprime son binaire et continue de fonctionner comme service en arrière-plan. Parallèlement, il se copie depuis la mémoire vers plusieurs emplacements du stockage. Il se cache derrière des noms a priori anodins, semblables à des fichiers système, pour tromper la vigilance. Aqua Security a résumé ces noms dans un graphique :
Le malware modifie également le script ~/.profile (configuration de l’environnement à la connexion de l’utilisateur) pour assurer son exécution lors de l’ouverture de session. Il dispose aussi d’un rootkit s’exécutant à tous les redémarrages de l’ordinateur.
Perfctl est en outre discret. En plus des mesures citées précédemment, il peut mettre fin automatiquement à toutes ses activités « bruyantes » quand un utilisateur se connecte sur la machine. Ses différents composants communiquent en interne en ouvrant des sockets Unix et en externe via des relais Tor.
Il sait aussi manipuler le processus pcap_loop (via une technique d’interception) pour empêcher les outils d’administration d’enregistrer le trafic qui pourrait être perçu comme malveillant. Le détournement de pcap_loop participe également à la persistance, en permettant aux activités malveillantes de se poursuivre quand les charges utiles ont été détectées et supprimées. En outre, Perfctl peut supprimer les erreurs mesg pour éviter que des avertissements apparaissent pendant l’exécution.
Une provenance incertaine
Un grand flou entoure Perfctl, en dépit des nombreux détails découverts par les chercheurs. Ils ne savent ni d’où il vient, ni quel groupe malveillant pourrait en être à l’origine. Aqua Security estime cependant que le degré de technicité est très élevé. L’accumulation des méthodes prouve que le ou les auteurs connaissent parfaitement le fonctionnement de Linux.
Il est tout autant difficile de savoir combien de machines sont infectées. Perfctl cherche en premier lieu à exploiter certaines failles, dont CVE-2023-33426, une vulnérabilité critique de dangerosité maximale (10 sur 10) dans Apache RocketMQ. Même s’il n’en trouve pas, il peut quand même passer par d’autres moyens, en exploitant plus de 20 000 erreurs courantes dans les configurations. Dans ce cas, il tente d’exploiter la faille CVE-2021-4043 dans Gpac pour obtenir les droits root.
La détection est d’autant plus difficile que Perfctl arrête ses activités les plus visibles dès qu’une session est ouverte, comme déjà précisé. Les chercheurs mettent en avant de nombreuses conversations sur des comportements étranges de leurs serveurs, notamment sur Reddit. « Je n'ai pris conscience de l'existence du logiciel malveillant que lorsque ma configuration de surveillance m'a alerté de l'utilisation à 100 % du processeur. Cependant, le processus s'arrêtait immédiatement lorsque je me connectais via SSH ou la console. Dès que je me déconnecte, le logiciel malveillant reprend son cours en quelques secondes ou minutes », écrit ainsi un administrateur.
On trouve d’autres discussions du même type, dans diverses langues, sur des sites comme Stack Overflow, forobeta, brainycp ou encore Proxmox. Sur ces témoignages, les chercheurs d’Aqua ne peuvent être certains qu’il s’agit bien de Perfctl, mais ils indiquent que les symptômes correspondent.
À quoi sert Perfctl ?
Le malware est tenace et discret, mais à quelles fins est-il utilisé ? Les pics de consommation CPU donnent un indice : il sert essentiellement à miner de la cryptomonnaie Monero en installant le cryptomineur XMRIG. Les envolées à 100 % sur le CPU viennent du minage, extrêmement gourmand en puissance de calcul. Comme vu, l’activité s’arrête dès que l’on se connecte à une session.
Perfctl peut également réaliser du proxy-jacking. Il réutilise ainsi la bande passante non exploitée à d’autres usages. Dans un cas comme dans l’autre, la motivation est clairement financière.
En dépit de ces deux activités, Perfctl est décrit par les chercheurs comme très polyvalent. En fonction de la charge utile envoyée par le serveur de commande et contrôle (C2C), il peut se livrer à d’autres actions malveillantes, comme l’exfiltration de données.
S’en débarrasser n’est pas simple
On ne sait pas vraiment si les antivirus sont capables actuellement de détecter Perfctl et de le supprimer. Les chercheurs d’Aqua Security fournissent quand même une série de conseils, notamment sur la manière de reconnaitre la présence du malware.
Il y a deux principaux critères pour établir la présence du malware. D’abord, les pics d’activité CPU (ou des ralentissements a priori inexpliqués), particulièrement sur des processus nommés httpd et sh. Ensuite, la présence de binaires suspects dans les dossiers /tmp, /usr et /root. Des noms comme perfctl, sh, libpprocps.so, perfcc et libfsnkdev.so sont donnés en exemples.
Aqua recommande en outre de vérifier les journaux système à la recherche de modifications sur les fichiers ~/.profile, et /etc/ld.so.preload, ainsi que la surveillance des modifications à certains utilitaires système (comme ldd, top, lsof et crontab).
Les chercheurs recommandent également plusieurs mesures d’atténuation, dont la plus importante est de mettre à jour les composants du serveur, en particulier ceux touchés par des failles exploitées. Aqua suggère aussi de restreindre l’exécution des fichiers dans les répertoires accessibles en écriture, de désactiver les services inutilisés, d’appliquer une gestion stricte des privilèges et, bien sûr, de déployer des outils de sécurité capables de détecter des rootkits et malwares sans fichier.
Aqua estime qu’en tenant compte de la prévalence des failles ciblées et non corrigées, des millions de machines sont actuellement vulnérables à ce malware.
Perfctl, un malware Linux tenace
-
Un roi de l’évasion et de la persistance
-
Une provenance incertaine
-
À quoi sert Perfctl ?
-
S’en débarrasser n’est pas simple
Commentaires (28)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 04/10/2024 à 12h49
Peut-être que CrowdStrike peut s'en occuper
Le 04/10/2024 à 13h17
Le 04/10/2024 à 17h08
Le 04/10/2024 à 19h15
Le 04/10/2024 à 21h38
Le 04/10/2024 à 13h29
Y a-t-il un centre de commandement qui écoute les IP exposées et utilise des failles de protocoles comme SSH, Apache, Nginx, etc ?
Infiltration type worm ?
Supply chain ?
Infection de dépôt logiciels ?
Au vu de ses capacités, il est forcément installé avec des droits root. Donc soit il utilise une faille d'escalade de privilèges, soit il est amené au moment d'une opération parfaitement justifiée.
Les conseils prodigués sont effectivement les gestes habituellement recommandés : isolation, process qui ne tournent pas en root quand c'est pas justifié (container inclus, pas de putain de user root !), least privilege, isoler son réseau (entrée et sortie), mettre du WAF, maintenir le système ET les middlewares à jour, etc. Hélas, la réputation fausse de "Linux = pas de malware" est encore bien trop ancrée dans les esprits, cette désinformation créé des ravages en matière de sécurité IT.
Modifié le 04/10/2024 à 17h04
Cela dit, le truc chiant avec les produits Apache c'est que la fondation ne se limite qu'à fournir les sources, le binaire et la doc (+/- laconique selon les produits). Il n'y a jamais les paquets pour les distrib ou a minima des instructions claires d'intégration, donc l'intégration se fait souvent à l'arrache c-a-d en root, sauf pour les trucs vraiment connus type httpd qui sont maintenus côté distrib.
Je ne compte plus le nombre de fois où j'ai vu du ambari (et hadoop en général), cassandra, kafka, solr, zookeeper etc. tourner en root. (et accessoirement jamais mis à jour).
Modifié le 04/10/2024 à 13h30
Même question que mon vdd, comment elle s'installe ?
Le 04/10/2024 à 13h48
Service qui tourne avec privilèges, utilisation d'une faille qui fait une escalade et kaboom. Je pense qu'avec du hardening (cf les différentes actions non exhaustives que je listais) les risques peuvent être déjà un peu plus mitigés.
Le 04/10/2024 à 13h32
Le 04/10/2024 à 13h54
Modifié le 04/10/2024 à 13h53
Le 04/10/2024 à 14h37
Le 04/10/2024 à 16h14
Crowdstrike nous protégera en enfermant le PC dans une boucle spatio-temporelle de reboots infinie
Modifié le 05/10/2024 à 10h42
Le 05/10/2024 à 12h51
zyva, installes une béta en prod ...
Le 04/10/2024 à 23h13
!/usr/bin/bash
MatchCount=0
ThreatFiles=("/tmp/.xdiag/hroot/cp"\
"/tmp/.xdiag/hroot/hscheck"\
"/tmp/.xdiag/tordata/state.tmp"\
"/tmp/.xdiag/hroot/cp"\
"/tmp/.xdiag/cp"\
"/tmp/.xdiag/exi"\
"/tmp/.xdiag/p"\
"/tmp/.xdiag/elog"\
"/tmp/.xdiag/int/.e.lock"\
"/tmp/.xdiag/uid"\
"/tmp/.xdiag/ver"\
"/tmp/.perf.c/Loader"\
"/tmp/.perf.c/perlctl"\
"/tmp/.apid"\
"/tmp/lgctr"\
"/tmp/lgctr2"\
"/usr/bin/.local/bin/ldd"\
"/usr/bin/.local/bin/top"\
"/usr/bin/perfcc"\
"/usr/bin/wizlmsh"\
"/tmp/lib/libfsnldev.so"\
"/tmp/lib/libcwrap.so"\
"/tmp/lib/libpprocps.so"\
"/root/.cache/pci.ids"\
"/root/.config/cron/perfcc"\
"/root/sedkBrgaa"\
)
echo "Let's chech files:"
for CurFile in "${ThreatFiles[@]}"; do
echo -e -n ' ├─ Looks for \E[34;01m'$CurFile'\E[0m : '
if [[ -e $CurFile ]]; then
echo -e '\E[31;01m✘\E[0m File found!'
((MatchCount++))
else
echo -e '\E[32;01m✔\E[0m No theat'
fi
done
if (( $MatchCount > 0 )); then
echo -e ' ╰─ \E[31;01mOH NOOOOOO! '$MatchCount' files found \E[0m'
else
echo -e ' ╰─ \E[32;01mGROOVY BABY!\E[0m'
fi
Le 05/10/2024 à 16h47
Et pour surveiller le process le plus actif sur une machine (ça produit un csv dans le dossier courant avec le process le plus actif chaque minute, par défaut) :
#!/bin/bash
OUTPUT_FILE=${1:-cpu_usage_history.csv}
PS_ARGS=(-axo '%cpu,pid,ppid,user,group,nice,stat,start,time,command' --sort=-%cpu)
INTERVAL_S=${2:-60}
prefix_with() {
prefix="$1"
cat "$OUTPUT_FILE"
while sleep "$INTERVAL_S"; do
ps "${PS_ARGS[@]}" | sed -e '2p;d' | prefix_with $(date +%s) >> "$OUTPUT_FILE"
done
Le 05/10/2024 à 18h53
Modifié le 06/10/2024 à 00h03
Juste 2 toutes petites typo "d'affichage" (sans importance) :
" No theat " >> " No threat "
" Let's chech files: " > > "Let's check files: "
Le 06/10/2024 à 09h34
!/usr/bin/bash ⇒ #!/usr/bin/bash
Le 06/10/2024 à 18h12
Forcer les gens à se poser des questions avant de lancer un script pourrait être une bonne chose aussi.
Le 06/10/2024 à 10h29
Remplacez "\" (en fin de ligne) par "," dans la liste "ThreatFiles". C'est un peu plus passe partout.
Et on n'oublie pas de lire le code AVANT de copier-coller pour les autres (sauf ton respect Wanou).
Accessoirement, une petite personnalisation pour le fun:
if (( $MatchCount > 0 )); then
echo -e ' ╰─ \E[31;01mOH NOOOOOO! They got Pablo! Free Pablo you evil dicks!!! '$MatchCount' files found \E[0m'
else
echo -e ' ╰─ \E[32;01mGROOVY (https://www.youtube.com/watch?v=FIJTvEo4N4Q)\E[0m'
fi
À noter que le problème sous-jacent n'est pas forcément vos serveurs dans le pro, mais aussi vos équipements perso. Un NAS, une imprimante 3D (ou tout IOT) qui héberge bien souvent des services sans pour autant que cela soit nécessaire ferait aussi une cible (facile ?). La puissance des SBC (et même d'un ESP32 sur lequel on peut faire tourner un Linux (hé oui)) est devenue intéressante.
Quand on détourne des I/O il n'y a pas de petites économies. Car il est un fait, on n'a pas toujours accès sur ces équipements de la façon dont on voudrait. Et donc se débarrasser d'une vérole pour madame Michu... Ca se complique.
À plus forte raison quand ces équipements ne sont pas suffisamment mis à jour (utilisateurs et constructeurs inclus). Pas de panique pour autant vos "box" font pas mal le boulot. Restera la gaffe d'installer un truc pas clean. Mais bon madame Michu... elle ne fait pas de Docker.
Ce genre d'épisode est le plus gros caillou dans la chaussure de l'Open / free source. On est passé de l'ère du "Oh putain ça marche!!! Groovy..." à celle de "hmm d'où ça sort ce truc ?". On commence à avoir du mal à compter les épisodes de fuite de donnée ou de détournement de package (Hein NPM!!!!). Bref "mettez des préservatifs", "Touches pas à mon pote", "Shampoing à l'Aloe Vera", "Mangez, bougez"* et tout ça quoi.
Le 05/10/2024 à 12h45
Modifié le 05/10/2024 à 15h22
Et quand t'arrives à négocier un patch management mensuel avec le métier, tu débouches le champagne.
Une résultante aussi des architectures pour lesquelles la redondance a été écartée parce que "trop cher". Résultat, pour reboot un serveur, il faut une inter en HNO planifiée 6 mois à l'avance.
Vive les visions court terme, vive les VM, vive le IaaS, vive les projets à 2 millions d'euros sur trois ans pour changer quatre serveurs en CentOS 6.
Toute ressemblance blablabla...
(et j'arrive à voir le même délire sur du container...)
Le 05/10/2024 à 15h44
Modifié le 06/10/2024 à 12h38
La partie la plus embêtante reste la gestion du brassage et la conception de mécanismes de rejeu en cas de perte/coupure d'un traitement en cours.
C'est de l'architecture d'infrastructure, et il y a des solutions techniques aux problèmes techniques.
Cependant, le souci vient majoritairement toujours d'ailleurs, et n'est pas technique : les DSI sont encore aujourd'hui vues comme des centres de coûts et non pas comme des centres d'investissement voire de création de valeur.
Ce malentendu empêche de ponctionner les revenus pour garantir un financement décent niveau technique & niveau humain.
Ce malentendu empêche aussi l'autonomie nécessaire des DSI, à qui on ne doit demander que de respecter des objectifs de service (SLO), qui vont déterminer le niveau de service ainsi que la durée d'évaluation, découlant parfois (mais pas toujours !) d'accords juridiques signés (SLA). Le point clé est qu'elles devraient rester libres de leur implémentation.
Il est grand temps qu'une culture informatique s'installe chez les moins techniques, afin notamment qu'ils mettent leurs peurs en sourdine, sans donc les déverser sur les connaisseurs et bloquant leurs moyens d'action, d'appliquer leurs connaissances, et ainsi de tout simplement faire leur métier.
Et quand bien même on se ferait de grandes séances d'onanisme à coups de SLO, shit happens.
Et il y a d'autres problèmes organisationnels, jusqu'à notre manière de travailler, mais commençons déjà quelque part.
Le 07/10/2024 à 15h41